在做比較複雜的專案時，當時思考維護上的難易度，想要一個 DAG 負責一個主要的功能就好。

舉例你是一個服飾品牌的資料工程師，現在你的 ETL 流程想整合各店市庫存跟銷售的資料，以判斷銷售的熱區跟庫存的管理。或甚至進一步的機器學習模型建製以預測我們庫存要備貨多少。

現在我們可以把這整個的 ETL 流程都寫在一個 DAG，但程式碼可能會變得上千行，如果要好管理，我會以以下方式來分 DAG :

1. 庫存資料 ETL
2. 銷售資料 ETL
3. 建模資料前置作業 + 建模
   這樣分的話，如果某個 DAG 執行失敗時，要 de-bug 的範圍也會小很多，管理起來也比較方便。

再來談一下 DAG 中的 task 怎麼切。
我是以該主要功能再細切成幾個比較能區分的任務，我們來談談庫存資料 ETL 這個 DAG 吧。
也許你的 source 是單一來源，也可能是多個來源，那可能的任務會怎麼切呢？

1. 將不同資料來源整合
2. 進行資料清理、匯整
3. 轉存進資料庫
   這樣區分的好處也是比較容易維護，還有其他人在讀這個 DAG 時也比較能進行有效率的解讀。

難得的小結一下 :

將專案的功能切分成獨立主要功能的 DAG -> 將每個主要功能的 DAG 切分成可區分的任務，即 task